Determining whether a person or object is present and available for interaction or use has been, and likely will remain, an everyday occurrence in society. As technology has evolved, so too have the ways in which we can determine the presence of persons or objects to interact with. For example, the explosive growth over the past two decades in the use of computers and their internetworking via wide-area networks (WANs), such as the Internet, has led to the development and use of presence services. Presence services can be used to convey a user's presence on a network to other network users based on user's connectivity to the network via a computing and/or communication device. Information describing users' presence on a network can be used by applications and/or other services to provide what are referred to here as “presence aware applications”.
One of today's more popular presence aware applications is instant messaging (or IM). Popular IM applications include Yahoo's YAHOO MESSENGER, Microsoft's MSN MESSENGER, and America Online's AOL INSTANT MESSENGER (or AIM). IM applications use presence services to allow users to determine whether other users (referred to by these applications as “friends” or “buddies”) are present on (e.g., connected to) a network. Presence services can also be used to determine a user's status (e.g., available, not available, and the like) and a communication address for communicating with a user. The communication address can include both a means of communicating with the user (e.g., via a telephone or email) and a corresponding contact address (e.g., a telephone number or email address).
The architecture, models, and protocols associated with presence services in general are described in “Request for Comments” (or RFC) documents RFC 2778 to Day et al., titled “A Model for Presence and Instant Messaging” (February 2000), and RFC 2779 to Day et al., titled “Instant Messaging/Presence Protocol” (February 2000), each published and owned by the Internet Society. While the various presence aware IM applications described above may use proprietary architectures and protocols to implement their presence service components, each of the applications use presence architectures and protocols that are consistent with the presence model and protocols described in RFC 2778 and RFC 2779 in terms of features and function.
The presence service model described in RFC 2778 describes two distinct users of a presence service, referred to as presence “clients”. The first of these clients, called a presentity (combining the terms “presence” and “entity”), provides presence information to be stored and distributed throughout the presence service. Presence information includes the status of a user of the presence service and may include additional information used by the service. This additional information can include, for example, the communication means and contract address of the user as described above. Presence information can be stored or maintained in any form for use by the presence service, but typically is organized into portions referred to as presence tuples. As will be understood by those skilled in the art, a tuple, in its broadest sense, is a data object containing one or more components. Thus, a presence tuple can include an identifier of a user and the user's status, contact address, or other information used by the presence service.
The second type of presence client is referred to as a “watcher”. Watchers receive presence information from the presence service. The presence model of RFC 2778 describes types of watchers, referred to as “subscribers” and “fetchers”. A subscriber requests notification from the presence service of a change in some presentity's presence information. The presence service establishes a subscription on behalf of the subscriber to a presentity's presence information, such that future changes in the presentity's presence information are “pushed” to the subscriber. In contrast, the fetcher class of watchers requests (or fetches) the current value of some presentity's presence information from the presence service. As such, the presence information can be said to be “pulled” from the presence service to the presentity. A special kind of fetcher, referred to as a “poller”, is defined in the model that fetches information on a regular (or polling) basis.
The presence service can also manage, store, and distribute presence information associated with watchers, as well as the watchers' activities in terms of the fetching or subscribing to the presence information of other presence clients using the presence service. This “watcher information” can be distributed to other watchers by the presence service using the same mechanisms that are available for distributing the presence information of presentities. It will be understood that while the model describes the presentity and watcher as separate entities, these entities can be combined functionally as a single presence entity having the characteristics of both a presentity and a watcher. Accordingly, the phrase “presence entity” (in contrast to the term “presentity”) or more simply the term “entity” with an appropriate modifier (e.g., responding, requesting, receiving, or sending) will be used throughout this document to describe any one or any combination of all of the presentity, watcher, subscriber, fetcher, or poller entities described above.
Users of the presence service are referred to in the presence model described in RFC 2778 as principals. Typically, a principal is a person or group that exists outside of the presence model, but can also represent software or other resources capable of interacting with the presence service. The model does not define the requirements or functionality of principals, but does state that two distinct principals be distinct, and two identical principals be identical. For purposes of this document, this strict interpretation of principals should not be adopted—that is, two distinct principals need not be distinct, and two identical principals need not be identical. For example, the 3rd Generation Partnership Project (3GPP) has included standards for incorporating presence services into their Universal Mobile Telecommunications System (UMTS) that define the use of “public identities” for users of the UMTS. A particular UMTS user may have several public identities. Consequently, were such a public identity to be construed as a principal, the public identity as a principal could be associated with more than one presence client.
According to the general presence model described in RFC 2778, a principal can interact with the presence system through a presence user agent (PUA) or a watcher user agent (WUA). As in the case of the presentity and watcher clients to which these user agents interact, the presence and watcher user agents can be combined functionally as a single user agent having both the characteristics of the presence and watcher user agents. User agents can be implemented such that their functionality exists within the presence service, external to the presence service, or a combination or both internal and external to the presence service.
Most presence aware applications, such as IM, use presence services only to determine an application user's presence, status, and communication address. For example, IM applications do not use the presence service itself to deliver core application services and information, such as the instant messages themselves, to their users. More specifically, IM applications do not use the base presence protocol messages (or commands) to exchange instant message information, but instead rely on a separate and distinct instant message protocol (see, e.g., RFC 2778 and RFC 2779) to exchange this information.
Likewise, other presence aware applications and extensions to presence services would be expected to use new protocols to support these applications or extended services. For example, to create a presence aware application capable of providing request/response services, developers would be expected to use a specific request/response protocol, separate from the presence protocol, to support the request/response services. Examples of request/response protocols include Hypertext Transfer Protocol (HTTP), used, for example, to exchange information between clients and servers over the Internet, and Simple Mail Transfer Protocol (SMTP) used for exchanging email messages over a network.
Indeed, the standards track publications RFC 3920 to Saint-Andre, titled “Extensible Messaging and Presence Protocol (XMPP): Core” (October 2004), and RFC 3921 to Saint-Andre, titled “Extensible Messaging and Presence Protocol (XMPP): Instant Messaging and Presence” (October 2004), each published and owned by the Internet Society, envision the use of separate protocols for supporting presence and request/response services. These publications describe a protocol for streaming Extensible Markup Language (XML) elements to exchange structured information in close to real time between any two network endpoints. Rather than combining both presence information and request/response information into a common XML stanza to be carried using only a presence protocol, XMPP defines the use of a first XML stanza (a “/presence” stanza) for carrying presence information and a separate, second XML stanza (an “/iq” stanza) for carrying request/response information (see, e.g., RFC 3920; section 9). These separate stanzas would then be carried by respective presence and request/response protocol layers.
Others have described arrangements for sending application information using a presence service, but fall short of providing general request/response services using a presence protocol. For example, U.S. Patent Application No. 200410122896 A1 to Gourraud, titled “TRANSMISSION OF APPLICATION INFORMATION AND COMMANDS USING PRESENCE TECHNOLOGY”, describes a presence entity that publishes application information or commands destined to a certain application, in the form of a presence tuple. The watcher subscribes to presence information associated with the certain application, and once authorized, receives the tuple with the application information or command.
In a first embodiment, Gourraud's arrangement sends an application identifier from user equipment to an application server using a presence service. The application server then sends predefined information to the user equipment using the presence service. The arrangement does not allow the user equipment to request specific information or services from the application server—only the predefined information may be received. Indeed, no mechanism is described in Gourraud's first embodiment for sending a request from the user equipment to the application through using the presence service or presence protocol. In a second embodiment, Gourraud's arrangement allows a command to be sent from the user equipment to an application server using a presence service. Only an acknowledgment that the command was executed by the server is sent to the user equipment. Moreover, the acknowledgment is sent using a separate protocol from the presence protocol, i.e., an instant message confirmation is sent using the Session Initiation Protocol (SIP). As such, no response is sent from the application server to the user equipment in Gourraud's second embodiment, nor is any mechanism described in the embodiment for sending such a response using the presence service or presence protocol.
Rather than using multiple protocols to support a presence aware application that is capable of providing request/response services, it would be more efficient and desirable to have an arrangement for providing a general request/response messaging protocol using a presence service and its underlying presence protocol.